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(57) Abrege : Le proc&ie* permet de verifier que des donnees recues par un recepteur (2) ont 6te envoy£es par un Smetteur (1, 
3) autorise" par un tiers de confiance, l'emetteur et le recepteur 6tant raccordSs a un nSseau numerique. Un identifiant (IdEvent) 
est associe* aux donnees envoy^es par F6metteur et, lorsque les donnees sont recues par le recepteur (2), celui-ci g6nere un nombre 
ateatoire (C) qu'il diffuse sur le reseau. L'emetteur qui recoit ce nombre aleatoire calcule une reponse (R) en appliquant une premiere 
fonction (G) au nombre aleatoire (C) et a l'identifiant (IdEvent) et envoie cette reponse (R) au recepteur qui venfie la reponse recue 
en appliquant une seconde fonction (H) a la reponse recue, au nombre aleatoire (C) et a l'identifiant (IdEvent). La premiere fonction 
(G) est dSlivree au pnSalable a l'emetteur par le tiers de confiance et la seconde fonction (H) est une fonction de verification du 
rdsultat de la premiere fonction, d61ivn§e au pr6alable par le tiers de confiance au recepteur. 
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Procede d'authentification anonvme d' un emetteur de donnees 

Domaine de I'invention 

La presente invention concerne I'echange securise de donnees a 
travers un reseau reliant differents dispositifs et I'authentification de la source 
de donnees emises sur un reseau. 

Etat de la technique 

Dans certains cas, il est necessaire pour un dispositif recepteur de 
donnees d'etre sQr que I'emetteur qui a diffuse les donnees etait bien autorise a 
le faire par un tiers de confiance sans que le recepteur des donnees ne 
connaisse I'identite de I'emetteur, les donnees etant egalement susceptibles 
d'etre relayees par un dispositif intermediate. Or tous les schemas connus 
d'authentification d'un emetteur de donnees impliquent que le recepteur des 
donnees connaisse I'emetteur. 

Expose de I'invention 

Un but de I'invention est done de proposer une methode permettant 
a un emetteur de donnees de prouver qu'il etait bien autorise a emettre les 
donnees par un tiers de confiance sans que le recepteur des donnees ne 
connaisse I'identite de I'emetteur. 

A cet effet, I'invention concerne un procede permettant de verifier 
que des donnees rogues par un recepteur ont ete envoyees par un emetteur 
autorise par un tiers de confiance, I'emetteur et le recepteur etant raccordes a 
un reseau numerique. Selon I'invention, un identifiant est associe aux donnees 
envoyees par I'emetteur et le procede comprend les etapes consistant, pour le 

recepteur, a : 

(a) generer un nombre aleatoire ; 

(b) diffuser sur le reseau ledit nombre aleatoire ; 

(c) recevoir de I'emetteur une reponse calculee en appliquant une 
premiere fonction audit nombre aleatoire et audit identifiant ; et 

(d) verifier la reponse recue en appliquant une seconde fonction a la 
reponse recue, audit nombre aleatoire et audit identifiant ; 

la premiere fonction ayant ete au prealable delivree a I'emetteur par 
le tiers de confiance et la seconde fonction etant une fonction de verification du 
resultat de la premiere fonction, delivree au prealable par le tiers de confiance 
au recepteur. 
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L'emetteur peut etre soit I'emetteur initial des donnees dans le 
reseau, soit un intermediaire entre I'emetteur initial et le recepteur des donnees 
qui a par exemple stocke les donnees emises par l'§metteur initial. 

Selon une variante de I'invention, I'etape (b) est remplacee par une 
5 etape consistant a envoyer le nombre aleatoire a I'emetteur. 

Selon un mode de realisation de I'invention, le r6cepteur interdit 
I'acces aux donnees si la reponse recue a I'etape (c) n'est pas correcte ou si 
aucune reponse n'est recue apres I'expiration d'un delai predetermine a 
compter de 1'emission du nombre aleatoire. 
10 L'identifiant associe aux donnees envoyees par I'emetteur est 

preferentiellement un nombre aleatoire genere par I'emetteur initial des 
donnees dans le reseau et attache a ces donnees par I'emetteur initial. Bien 
entendu, cet identifiant ne donne aucune information sur I'identite de I'emetteur. 

L'invention concerne egalement un procede pour prouver que des 
15 donnees envoyees a un recepteur ont ete emises par un emetteur autorise par 
un tiers de confiance, I'emetteur et le recepteur etant raccordes a un reseau 
numerique. Selon cet aspect de I'invention, un identifiant est associe aux 
donnees envoyees par I'emetteur et le procede comprend les etapes 
consistant, pour I'emetteur a : 
20 (a) recevoir un nombre aleatoire du recepteur ; 

(b) calculer une reponse en appliquant une premiere fonction audit 
nombre aleatoire et audit identifiant ; 

(c) envoyer la reponse au recepteur. 

La reponse est susceptible d'etre verifiee par le recepteur en 
25 appliquant une seconde fonction a la reponse recue, audit nombre aleatoire et 
audit identifiant; la premiere fonction ayant ete au prealable delivree a 
I'emetteur par le tiers de confiance et la seconde fonction etant une fonction de 
verification du resultat de la premiere fonction, delivree au prealable par le tiers 
de confiance au recepteur. 
30 Selon le principe de I'invention, un tiers de confiance delivre a tous 

les dispbsitifs susceptibles d'etre des emetteurs initiaux ou intermediaires dans 
un reseau, la premiere fonction permettant de calculer la reponse dans le cadre 
du procede ci-dessus. Le tiers de confiance delivre egalement a tous les 
dispositifs susceptibles d'etre des recepteurs dans le reseau, la seconde 
35 fonction permettant de verifier la reponse calculee a I'aide de la premiere 
fonction. 



WO 03/088612 PCT/FR03/01169 



Breve description des dessins 

L'invention sera mieux comprise a la lecture de la description qui va 
suivre, donnee uniquement a titre d'exemple et faite en se referant aux dessins 

annexes sur lesquels : 
5 - la figure 1 represente un reseau numerique domestique dans lequel 

est mise en ceuvre l'invention ; 

- les figures 2 et 3 illustrent deux exemples de mises en ceuvre de 

l'invention. 

10 Description detaillee de modes de r ealisation de l'invention 

Sur la base du principe de l'invention expose ci-dessus, plusieurs 

scenarios sont possibles. 

Selon un premier scenario, un premier emetteur, que nous 
appellerons Alice, et un second emetteur, que nous appellerons Charlie, 
1 5 diffusent des messages respectivement appeles M A et M c sur un reseau auquel 
est raccorde un recepteur, que nous appellerons Bob. Alice diffuse avec le 
message M A un identifiant IdEvenU qui identifie le message M A et Charlie 
diffuse avec le message M c un identifiant IdEventc qui identifie le message M c . 

Alice et Charlie qui sont tous deux raccordes au reseau recoivent 
20 respectivement les messages M c et M A emis par I'autre emetteur du reseau 
mais ils ne les conservent pas. Bob regoit egalement les deux messages et 
nous supposons qu'il ne souhaite conserver que le message M A . Pour etre sOr 
que M A provient d'une source autorisee par un tiers de confiance, Bob lance un 
protocole challenge/reponse de la maniere suivante. Bob genere un nombre 
25 aleatoire C (le challenge) puis il le diffuse sur le reseau. Alice et Charlie 
recoivent tous deux le challenge C. 

Au prealable, nous supposons que le tiers de confiance a delivre a 
Alice et Charlie une fonction G de calcul de reponse et a delivre a Bob une 
fonction H correspondante de verification de reponse telle que cette fonction H 
30 retoume 0 si la reponse est incorrecte et 1 si la reponse est correcte. 

Lorsque Alice et Charlie regoivent le challenge C emis par Bob, ils 
calculent respectivement des reponses R A et R c comme suit : 
Alice : R A = GfldEvenU, C) ; 
Charlie : R c = G(ldEventc, C) ; 
35 puis ils envoient respectivement les reponses R A et Rc a Bob. 

Bob verifie ensuite chaque reponse en calculant H(C, R x , ldEvent A ) 
pour X = A et C. Si tous les resultats retournes par la fonction H sont nuls, alors 
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Bob ne conserve pas le message M A qui est considere comme ne provenant 
pas d'une source sure. Par contre, si au moins un resultat retourne par H est 
egal a 1 (dans I'exemple, il s'agira de H(C, R A , ldEvent A )), alors Bob accepte le 
message M A car il est assure qu'il provient d'un emetteur autorise par le tiers de 
5 confiance. 

Selon un second scenario, un emetteur, Alice, diffuse un message 
M A accompagne d'un identifiant ldEvent A sur un reseau auquel est raccorde un 
recepteur Bob et une entite intermediaire, que nous appellerons Deborah. Dans 

10 un premier temps, nous supposons que Bob n'est pas interesse par le message 
M A et qu'il ne le conserve pas. Deborah par contre enregistre le message M A et 
son identifiant ldEvent A . 

Plus tard, alors qu'Alice ne diffuse plus de message, nous 
supposons que Deborah diffuse le message M A enregistre et son identifiant 

15 ldEvent A sur le reseau. Alice etant seulement un emetteur ne conserve pas M A . 
Bob recoit M A et souhaite le conserver. Pour s'assurer qu'il provient d'une 
source autorisee par un tiers de confiance, Bob lance un protocole 
challenge/reponse de la maniere suivante. Bob genere un nombre aleatoire C 
(le challenge) puis il le diffuse sur le reseau. 

20 Au prealable, nous supposons que le tiers de confiance a delivre a 

Alice et Deborah une fonction G de calcul de reponse et a delivre a Bob une 
fonction H correspondante de verification de reponse telle que cette fonction H 
retourne 0 si la reponse est incorrecte et 1 si la reponse est correcte. 

Alice et Deborah recoivent le challenge C. Comme Alice n'est pas en 

25 train de diffuser un message, elle ne tient pas compte du challenge C. Deborah 
par contre calcule une reponse R D = G(ldEvent A , C) et envoie cette reponse a 
Bob. Bob verifie ensuite cette reponse en calculant H(C, Rd, IdEvenU). Si la 
fonction H retourne 0, alors Bob ne conserve pas le message M A . En revanche, 
si la fonction H retourne 1, alors Bob accepte le message M A qui est considere 

30 comme provenant d'une source autorisee. 

On notera que dans les deux scenarios exposes ci-dessus, I'entite 
recepteur Bob, meme s'il est capable de repondre a la source du message, ne 
sait pas si le message qu'il recoit provient d'un emetteur (comme Alice) ou d'un 
35 intermediaire (comme Deborah) et surtout il ne connaTt pas I'identite du 
diffuseurdu message M A . 
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Nous allons maintenant decrire un exemple plus concret de mise en 
oeuvre de ('invention en reference a la figure 1 ou sont represents un decodeur 
STB (de I'anglais « Set Top Box ») 1, un recepteur de television numerique 
DTV (de I'anglais « Digital Television ») 2 et un dispositif d'enregistrement SU 
(de I'anglais « Storage Unit ») 3. 

Nous supposons que les donnees diffusees sur ce reseau 
represented des programmes audiovisuels composes de flux elementaires 
Audio et Video transports dans un flux de transport de donnees tel que defini 
dans la norme ISO/I EC 13818-1 « Information technology - Generic coding of 
moving pictures and associated audio information : Systems ». 

Le decodeur 1 represente un emetteur de donnees sur le reseau, il 
emet des donnees qu'il recoit par exemple d'une antenne satellite ou d'une 
connexion au cable. Le televiseur numerique 2 represente un recepteur de 
donnees sur le reseau. Le dispositif d'enregistrement 3 represente quant a lui 
un dispositif intermediate capable de rediffuser sur le reseau des donnees 
reciies d'un autre dispositif emetteur du reseau. 

Ces trois dispositifs sont raccordes a un bus numerique 4, par 
exemple un bus selon la norme IEEE 1394, et ferment ainsi un reseau 
domestique numerique. Les messages diffuses dans le reseau sont envoyes a 
travers le canal isochrone du bus 4 et les messages qui sont adresses sont 
envoyes a travers le canal asynchrone du bus 4. 

Le tiers de confiance qui delivre une fonction G de calcul de reponse 
a un protocole challenge/reponse aux dispositifs emetteurs ou intermediaires du 
reseau (dans notre exemple, le decodeur 1 et le dispositif d'enregistrement 3) et 
qui delivre une fonction H de verification de reponse aux dispositifs recepteurs 
du reseau (dans notre exemple le televiseur numerique 2) est par exemple le 
fabriquant des dispositifs. 

En ce qui concerne le choix des fonctions G et H, nous envisagerons 

trois modes de realisation. 

Selon un premier mode de realisation prefere, la fonction G est une 
fonction publique qui utilise une cle secrete K pour calculer une reponse R a 
partir d'un challenge C et d'un identifiant IdEvent (i.e. R = G K (C, IdEvent)). Pour 
garantir que les dispositifs emetteurs ou intermediaires sont des appareils 
conformes, autorises par le tiers de confiance, le secret K est insere dans ces 
dispositifs, dans une zone de stockage securisee qui ne doit plus etre 
accessible ulterieurement (par exemple dans un processeur securise, 
notamment inclus dans une carte a puce). 
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La fonction H est dans ce cas une fonction qui calcule une reponse 
R' a partir du challenge C et de I'identifiant IdEvent en appliquant la fonction G 
avec la cle secrete K et qui compare ensuite le resultat R' avec la reponse R 
regue. H est une fonction booleenne qui delivre une valeur nulle « 0 » si R' est 
5 different de R et qui delivre une valeur « 1 » si R' est egal a R. Dans ce cas, la 
cle secrete K doit aussi etre inseree au prealable par le tiers de confiance dans 

les dispositifs recepteurs. 

Une fonction G correspondant a la definition ci-dessus peut etre 
notamment une fonction de chiffrement telle que la fonction AES decrite 

10 notamment dans « FIPS 197: Specification of the Advanced Encryption 
Standard (AES) -26 novembre 2001 » disponible a I'adresse Internet suivante : 
http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf. II peut egalement s'agir 
d'une fonction de hachage telle que la fonction HMAC-SHA1 decrite notamment 
dans « FIPS Publication 198: The Keyed-Hash Message Authentication Code 

15 (HMAC), National institute of Standards and Technology, 2001 » disponible a 
I'adresse Internet suivante : http://csrc.nist.gov/publications/fips/fips198/fips- 

198a.pdf. 

Dans un second mode de realisation, la fonction G est une fonction 
20 secrete qui est inseree dans les dispositifs emetteurs ou intermediaires 
consideres comme conformes et autorises par le tiers de confiance. 
Preferentiellement, cette fonction doit §tre choisie de maniere a etre tres 
difficilement retrouvee par I'analyse des produits qui la contiennent. De plus 
cette fonction doit etre resistante aux attaques adaptatives a texte Clair choisi 
25 (plus connues sous le nom anglais de « adaptive chosen-plaintext attacks »). 

De meme que dans le premier mode de realisation, la fonction H est 
dans ce cas une fonction booleenne qui calcule une reponse R' a partir du 
challenge C et de I'identifiant IdEvent en appliquant la fonction G secrete et qui 
compare ensuite le resultat R' avec la reponse R regue, delivrant une valeur 
30 nulle « 0 » si R' est different de R et delivrant une valeur « 1 » si R' est egal a 
R. Dans ce mode de realisation, la fonction secrete G doit done aussi §tre 
inseree au prealable par le tiers de confiance dans les dispositifs recepteurs. 

Dans un troisieme mode de realisation, les fonctions G et H sont des 
35 fonctions publiques utilisant une paire de cles asymetrique (cle privee/cle 
publique). La fonction G est par exemple une fonction de generation de 
signature a I'aide d'une cle privee et la fonction H est une fonction de 
verification de signature a I'aide de la cle publique correspondante. 
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Nous utiliserons par exemple les fonctions de signature RSA 
(acronyme du nom des createurs Rivest, Shamir et Adleman) comme suit : 

R = G(C, IdEvent) = RSASign K pRi(C, IdEvent) et 

H(C, R, IdEvent) = RSAVerif K PUB(C, R, IdEvent); ou KPRI et KPUB 
sont la cle privee et la cle publique d'une meme paire de cle RSA. 

Dans ce cas, la cle privee est inseree dans les dispositifs emetteurs 
ou intermediates du reseau par le tiers de confiance et la cle publique est 
inseree dans les dispositifs recepteurs du reseau. 

Nous supposerons dans la suite que le premier mode de realisation 
a ete choisi dans lequel la fonction G est la fonction HMAC-SHA1 et qu'une cle 
secrete K est incluse dans une zone de stockage inviolable du decodeur STB 1, 
du recepteur de television numerique DTV 2 et du dispositif d'enregistrement 
SU 3. 

Premier scenario : le STB transme t directement un programme au 

DTV 

Comme illustre a la figure 2, lorsque I'utilisateur du decodeur STB 1 
selectionne un nouveau programme pour qu'il sort diffuse dans le reseau, le 
STB genere aleatoirement un identifiant de programme IdEvent (etape 20), qui 
est preferentiellement un nombre de 128 bits et il insere cet identifiant dans des 
messages contenus dans les paquets de transport des donnees representant le 
programme. Le flux de transport de donnees est ensuite diffuse sur le reseau 
(sur le canal isochrone du bus 4) lors de I'etape 21. II est recu par le televiseur 
numerique DTV 2 qui extrait des paquets de donnees regus les messages 
contenant I'identifiant pour finalement recuperer cet identifiant IdEvent (etape 
22). 

Le DTV genere alors a I'etape 23 un challenge C, qui est 
preferentiellement un nombre aleatoire de 128 bits, et il diffuse ce challenge C 
sur le reseau lors de I'etape 24. Lorsque le STB recoit le challenge C, il calcule 
a I'etape 25 la reponse : 

R = G(C, IdEvent), ou plus precisement : 

Rstb = HMAC-SHA1 K (C, IdEvent) 

et adresse cette reponse au DTV par le canal asynchrone du bus 4 
(etape 26). 

Le dispositif d'enregistrement SU 3, qui regoit egalement le challenge 
C ne repond pas puisqu'il n'est pas en train de d'rffuser des donnees. 
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Lorsque le DTV recoit la reponse R=R S tb du STB, il applique la 
fonction H (R, C, IdEvent) pour verifier la reponse R (etape 27), ce qui revient a 
cslculer i 

Row = HMAC-SHA1 K (C, IdEvent) et a comparer ce resultat a la 
5 reponse Rstb recue. Si les deux valeurs sont les memes, alors le DTV 
considere que le programme recu provient d'un emetteur autorise par le tiers de 
confiance et peut etre presente a I'utilisateur. Sinon, le DTV n'affiche pas a 
Tutilisateur le programme regu. Si le DTV ne recoit aucune reponse apres qu'un 
delai predetermine se soit ecoule depuis renvoi du challenge C sur le reseau, il 
1 0 bloque egalement I'affichage du programme recu. 

A la fin du protocole, le challenge C et I'identifiant IdEvent sont 
effaces des memoires du STB et du DTV. 

fiftnonri scenario : le STB transmet un programme qui est stocke par 
15 le SU qui le diffuse ulterieurement au DTV. 

Ce scenario est illustre par la figure 3. 

Dans un premier temps, on suppose que I'utilisateur du STB 
selectionne un nouveau programme. Le STB genere alors un identifiant IdEvent 
20 (etape 30) comme dans le premier scenario ci-dessus et il insere cet identifiant 
dans des messages inclus dans les paquets de transport des donnees 
representant le programme avant de diffuser le flux de transport de donnees sur 

le reseau (etape 31). 

Le SU enregistre ensuite le flux de donnees representant le 
25 programme. L'utilisateur a par exemple choisi de ne pas visualiser tout de suite 
le programme qui est diffuse par le decodeur et prefere I'enregistrer pour le 
relire plus tard. 

Dans un deuxieme temps, I'utilisateur souhaite relire le programme 
enregistre. Le SU diffuse done le programme sur le reseau lors d'une etape 32. 
30 Le DTV recoit les paquets de donnees et en extrait les messages contenant 
I'identifiant IdEvent a I'etape 33. 

Le DTV genere ensuite un challenge C comme dans le premier 
scenario (etape 34) et il diffuse ce challenge sur le reseau (etapes 35, 35'). 

Le SU recoit ce challenge C, il calcule done a I'etape 36 la reponse : 
35 R = G(C, IdEvent), ou plus precisement : 

R su = HMAC-SHA1 K (C, IdEvent) 

et adresse cette reponse au DTV par le canal asynchrone du bus 4 
(etape 37). 
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Le STB qui n'est pas en train de diffuser des donnees ne repond pas 
au challenge C qu'il regoit egalement. 

Lorsque le DTV regoit la reponse R=R SU du SU, il applique la 
fonction H (R, C, IdEvent) pour verifier la reponse R (etape 38), ce qui revient a 
5 calculer : 

Rdtv = HMAC-SHA1 K (C, IdEvent) et a comparer ce resultat a la 
reponse R su regue. Si les deux valeurs sont les memes, alors le DTV considere 
que le programme regu provient d'un emetteur autorise par le tiers de confiance 
et peut etre presente a I'utilisateur. Dans le cas contraire ou dans le cas ou 
10 aucune reponse n'a ete regue apres un delai predetermine suivant I'envoi du 
challenge C par le DTV, ce dernier n'affiche pas a I'utilisateur le programme 
regu. 

On notera que lorsque le STB a termine de diffuser le programme 
dans le premier temps, il efface ensuite i'identifiant IdEvent de sa memoire. 
15 A la fin du protocole, le challenge C et I'identifiant IdEvent sont 

egalement effaces des memoires du SU et du DTV. 

Dans une variante de realisation de I'invention, notamment dans les 
deux scenarii exposes ci-dessus, il est possible de remplacer I'etape de 

20 diffusion sur le reseau du challenge C calcule par le DTV par une etape d'envoi 
de ce challenge C a I'emetteur des donnees (le STB dans le premier scenario 
ou le SU dans le deuxieme scenario). Dans ce cas, seul I'emetteur des 
donnees regoit le challenge C. En effet, les protocoles existants de gestion des 
reseaux numeriques permettent a un recepteur de donnees de repondre a la 

25 source des donnees sans pour autant connaTtre son identite. 

Dans une autre variante de realisation, le recepteur des donnees 
diffuse sur le reseau, en plus du challenge C, I'identifiant IdEvent associe aux 
donnees qu'il a regu (par exemple a I'etape 24 dans la figure 2 ou a I'etape 35, 

30 35' dans la figure 3). Chaque appareil emetteur du reseau qui regoit le 
challenge C et I'identifiant IdEvent verifie s'il doit repondre a ce challenge en 
comparant I'identifiant IdEvent regu avec celui qu'il vient eventuellement de 
generer pour diffuser des donnees. L'emetteur ne repond que si I'identifiant 
regu avec le challenge correspond a son identifiant IdEvent courant. Ceci 

35 permet d'eviter que tous les emetteurs qui diffusent des donnees dans le 
reseau ne repondent lorsqu'un challenge C est envoye par un recepteur. 



L'invention presente notamment les avantages suivants : 
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M§me si plusieurs dispositifs emetteurs ou intermediates sont 
raccordes au reseau, seul celui qui a ete autorise par le tiers de conflance et qui 
a emis les donnees est capable de repondre au protocole challenge/reponse 
initie par le recepteur des donnees. 

Le protocole ne divulgue aucune information concernant I'emetteur 
au recepteur. Ceci permet d'atteindre I'objectif d'une authentification anonyme 

du dispositif emetteur. 

Le protocole repose uniquement sur la couche application et ne 
requiert aucune particularite au niveau de la couche transport des donnees. 
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REVENDICATIONS 



1 . Procede pour verifier que des donnees recues par un recepteur 
(2) ont ete envoyees par un emetteur (1, 3) autorise par un tiers de confiance, 
I'emetteur et le recepteur etant raccordes a un reseau numerique, caracterise 
en ce qu'un identifiant (IdEvent) est associe aux donnees envoyees par 
I'emetteur et en ce que le procede comprend les etapes consistant, pour le 

recepteur (2), a : 

(a) generer un nombre aleatoire (C) ; 

(b) diffuser sur le reseau ledit nombre aleatoire ; 

(c) recevoir de I'emetteur une reponse (R) calculee en appliquant 
une premiere fonction (G) audit nombre aleatoire (C) et audit identifiant 
(IdEvent) ; 

(d) verifier la reponse (R) recue en appliquant une seconde fonction 
(H) a la reponse recue (R), audit nombre aleatoire (C) et audit identifiant 
(IdEvent) ; 

la premiere fonction (G) ayant ete au prealable delivree a I'emetteur 
par le tiers de confiance et la seconde fonction (H) etant une fonction de 
verification du resultat de la premiere fonction, delivree au prealable par le tiers 
de confiance au recepteur. 

2. Procede selon la revendication 1, dans lequel I'etape (b) est 
remplacee par une etape consistant a envoyer ledit nombre aleatoire (C) a 
I'emetteur. 

3. Procede selon la revendication 1, dans lequel le recepteur diffuse 
en outre a I'etape (b) ledit identifiant (IdEvent). 

4. Procede selon Tune des revendications 1 a 3, caracterise en ce 
que le recepteur interdit I'acces aux dites donnees si la reponse (R) recue a 
I'etape (c) n'est pas correcte ou si aucune reponse n'est recue apres I'expiration 
d'un delai predetermine a compter de remission du nombre aleatoire (C). 

5. Procede pour prouver que des donnees envoyees a un recepteur 
(2) ont ete emises par un emetteur (1, 3) autorise par un tiers de confiance, 
I'emetteur et le recepteur etant raccordes a un reseau numerique, caracterise 
en ce qu'un identifiant (IdEvent) est associe aux donnees envoyees par 
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I'emetteur et en ce que le precede comprend les etapes consistant, pour 
I'emetteur (1,3) a: 

(a) recevoir un nombre aleatoire (C) du recepteur (2) ; 

(b) calculer une reponse (R) en appliquant une premiere fonction (G) 
5 audit nombre aleatoire (C) et audit identifiant (IdEvent) ; 

(c) envoyer ladite reponse (R) au recepteur (2) ; 

ladite reponse etant susceptible d'etre verifiee par le recepteur en 
appliquant une seconde fonction (H) a la reponse (R) recue, audit nombre 
aleatoire (C) et audit identifiant (IdEvent) ; 
10 la premiere fonction (G) ayant ete au prealable delivree a I'emetteur 

par le tiers de confiance et la seconde fonction (H) etant une fonction de 
verification du resultat de la premiere fonction, delivree au prealable par le tiers 
de confiance au recepteur. 

15 6. Precede selon la revendication 5, dans lequel I'emetteur recoit en 

outre a I'etape (a) ledit identifiant (IdEvent) associe aux donnees recues par le 
recepteur et dans lequel les etapes (b) et (c) ne sont effectuees que si ledit 
identifiant regu a I'etape (a) correspond a I'identifiant associe aux donnees que 
I'emetteur vient d'envoyer. 

20 

7. Precede selon Tune des revendications precedentes, caracterise 
en ce que I'identifiant associe aux donnees envoyees par I'emetteur est un 
nombre aleatoire genere par I'emetteur initial des donnees dans le reseau et 
attache aux dites donnees par I'emetteur initial. 

25 

8. Precede selon Tune des revendications precedentes, caracterise 
en ce que la premiere fonction (G) est une fonction publique utilisant une cle 
secrete. 

30 9. Precede selon la revendication 8, caracterise en ce que la 

seconde fonction (H) est une fonction booleenne 

calculant une reponse attendue en appliquant audit nombre aleatoire 
(C) et audit identifiant (IdEvent) la premiere fonction (G) avec la cle secrete et 
comparant la reponse attendue a la reponse recue pour delivrer : 
35 - une valeur « 0 » si les reponses attendue et recue sont 

differentes et 

- une valeur « 1 » si les reponses attendue et recue sont 

egales. 
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10. Procede selon Tune des revendications 1 a 7, caracterise en ce 
que la premiere fonction (G) est une fonction secrete. 

5 11. Procede selon la revendication 10, caracterise en ce que la 

seconde fonction (H) est une fonction booleenne 

calculant une reponse attendue en appliquant audit nombre aleatoire 
(C) et audit identifiant (IdEvent) la premiere fonction (G) et 

comparant la reponse attendue a la reponse recue pour delivrer : 
10 - une valeur «0» si les reponses attendue et recue sont 

differentes et 

- une valeur « 1 » si les reponses attendue et recue sont 

egales. 

15 12. Procede selon I'une des revendications 1 a 7, caracterise en ce 

que la premiere fonction (G) est une fonction publique de generation de 
signature a I'aide d'une cle privee. 

13. Procede selon la revendication 12, caracterise en ce que la 
20 seconde fonction (H) est une fonction publique de verification de signature a 
I'aide d'une cle publique correspondant a la cle privee utilisee par la premiere 
fonction. 
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(57) Abstract: The invention relates to a method 
whereby it can be checked whether data received by 
a receiver (2) has been sent by a transmitter (1, 3) 
authorised by a trusted third party, the transmitter and 
the receiver being connected to a digital network. An 
identifier (IdEvent) is associated with the data sent by 
the transmitter and, on receipt of the data by the receiver 
(2), the receiver generates a random number (C) and 
diffuses the same on the network. The transmitter that 
receives said random number calculates a response 
(R) by applying a first function (G) to the random 
number (C) and to the identifier (IdEvent), and sends 
said response (R) to the receiver which verifies the 
response received by applying a second function (H) to 
the response received, the random number (C) and the 
identifier (IdEvent). The first function (G) is delivered 
first to the transmitter by the trusted third party, and 
the second function (H) is a function for checking the 
result of the first function which is delivered first to the 
receiver by the trusted third party. 

(57) Abrege : Le proc&ie* permet de verifier que des don- 
nees revues par un recepteur (2) ont ete" envoyees par un 
emetteur (1,3) autorise par un tiers de confiance, Temet- 
teur et le recepteur etant raccordSs a un r6seau numerique. 
Un identifiant (IdEvent) est associe" aux donnees envoyees 
par V6 metteur et, lorsque les donnees sont recues par le re- 
cepteur (2), celui-ci genere un nombre aleatoire (C) qu'il 
diffuse sur le nSseau. U emetteur qui recoit ce nombre 
aleatoire calcule une reponse (R) en appliquant une pre- 
miere fonction (G) au nombre aleatoire (C) et a 1' identi- 
fiant (IdEvent) et envoie cette reponse 
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(R) au rScepteur qui verifie la reponse regue en appliquant une seconde fonction (H) a la reponse regue, au nombre aleatoire (C) et a 
ridentifiant (IdEvent). La premiere fonction (G) est delivree au prSalable a rSmetteur par le tiers de confiance et la seconde fonction 
(H) est une fonction de verification du resultat de la premiere fonction, d61ivr6e au prealable par le tiers de confiance au recepteur. 
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